RESERVATION OF COPYRIGHT
A portion of the disclosure of this patent document contains material to which a claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but reserves all other rights whatsoever.
1. Field of the Invention
The present invention relates to data acquisition (DAQ) systems, and particularly to an improved modular software architecture for a data acquisition system which provides code development simplification and increased code reuse.
2. Description of the Related Art
Scientists and engineers often use DAQ systems to perform a variety of functions, including laboratory research, process monitoring and control, data logging, analytical chemistry, test and analysis of physical phenomena, and control of mechanical or electrical machinery, to name a few examples. A DAQ system typically includes transducers and other detecting means for providing "field" electrical signals representing a process, physical phenomena, equipment being monitored or measured, etc. For example, detectors and/or sensors are used to sense the on/off state of power circuits, proximity switches, push-button switches, thermostats, relays or even the presence of positive or negative digital logic-level signals.
A typical DAQ system comprises a computer system with DAQ hardware, wherein the DAQ hardware is typically plugged into one of the I/O slots of the computer system. The field signals are provided to the DAQ hardware. In another common DAQ system configuration, the DAQ hardware is coupled to the computer system via other means such as through a VXI (VME extensions for Instrumentation) bus, a GPIB (General Purpose Interface Bus), a serial port, or parallel port of the computer system. Optionally, the DAQ hardware comprises signal conditioning modules which receive the field signals and condition the signals to be acquired.
The DAQ hardware is configured and controlled by DAQ software executing on the computer system. The DAQ software for configuring and controlling the DAQ system typically comprises two portions: the device interface or driver level software and the application software, or the application. The driver level software serves to interface the DAQ hardware to the application. The driver level software is typically supplied by the manufacturer of the DAQ hardware or by some other third party software vendor. The application is typically developed by the user of the DAQ system and is tailored to the particular function which the user intends the DAQ system to perform. The DAQ hardware manufacturer or third party software vendor sometimes supplies the application software for some applications which are common, generic or straightforward.
DAQ driver level software provides a high-level interface to the operations of the DAQ device. The DAQ driver level software operates to configure the DAQ device for communication and initialize hardware and software to a known state. The DAQ driver level software also generally maintains a soft copy of the state of the DAQ device and initiated operations. Further, the DAQ driver level software communicates over the bus to move the device from state to state and to respond to device requests.
Prior art DAQ driver level software, such as NI-DAQ version 4.0 from National Instruments, maintains a state for devices in a common set of data structures, wherein different data structures are used for different device functionality, such as analog input (AI), analog output (AO), digital I/O (DIO), etc. This prior art DAQ driver level software typically used arrays of data structures for replicated hardware primitives and also intermixed hardware programming and parameter validation. Further, the high-level functions were mostly generic, with device-specific cases singled out within the function.
Therefore, the current software architecture for DAQ driver level software, such as NI-DAQ from National Instruments, is centered around a legacy C application programming interface (API). In this current DAQ driver level software architecture, generic or hardware independent functionality was required to be implemented repeatedly for each board, and thus there was needless repetition of code. With the proliferation of device types, the amount of DAQ driver level software grew fairly large, with little re-use of code between devices.
Another complicating factor in the design of DAQ driver level software is access from multiple processes. In general, the DAQ driver level software must maintain a consistent state of the device across processes. One short-term solution is to allocate data structures from shared memory. In addition, the DAQ driver level software must allow safe multi-threaded access.
Another complicating factor in the design of DAQ driver level software includes user-mode/kernel-mode issues. In general, I/O access is speedier when using software executing in kernel mode. However, various issues arise for software executing in kernel mode. First, interrupts must be serviced from the kernel. Also, memory access levels are different, and file I/O and floating point operations are not recommended in the context of a kernel environment. In prior art DAQ driver level software, such as NI-DAQ 4.0 executing under Windows 95 and Windows 3.1, all foreground I/O was performed from user mode. The DAQ driver level software responded to device interrupts in kernel mode, and was required to map data required by the interrupt service routine (ISR) to user mode and kernel mode. The DAQ driver level software further utilized cumbersome, tricky techniques to handle user mode/kernel mode transitions. In NI-DAQ 4.0 executing under Windows NT, all foreground I/O and ISRs executed in kernel mode. Also, the data structures which maintained the device state were accessible only from the kernel environment. Further, the high-level functions perform floating-point (scaling) or file access to the configuration file in user mode.
It would be highly desirable for the DAQ driver level software architecture to allow for greater code reuse and simplification. In addition, it would be desirable for DAQ driver level software to provide more efficient user mode/kernel mode operation.
Therefore, an improved DAQ driver level software architecture is desired for controlling and/or accessing functionality of a DAQ device.